当我们在linux里面执行一个可执行文件报not found的时候如何处理,背后的原理是什么? 您所在的位置:网站首页 sha265 文件属性 当我们在linux里面执行一个可执行文件报not found的时候如何处理,背后的原理是什么?

当我们在linux里面执行一个可执行文件报not found的时候如何处理,背后的原理是什么?

#当我们在linux里面执行一个可执行文件报not found的时候如何处理,背后的原理是什么?| 来源: 网络整理| 查看: 265

第一步:问题以及解决方法

我们以blastp可执行文件为例,当我们从官方https://ftp.ncbi.nlm.nih.gov/blast/executables/blast+/LATEST/ 下载 x64-linux的可执行文件进到我们的镜像里面之后,我们执行blastp 可执行程序的时候会报not found的错误:

# /blast/bin/blastp sh: /blast/bin/blastp: not found

这个时候我们可以先通过file 命令查看一下可执行文件的文件属性

# file /blast/bin/blastp /blast/bin/blastp: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ae02b977590d4c61164674c1b4c69aa06bb9be40, stripped

我们可以看到其是一个简单的可移植性文件里面有一些动态 链接库的依赖,并且运行在linux-x86-64 的版本上面 linux 内核里面

然后我们再通过ldd 查看一下可执行文件依赖的动态库有哪些?

# ldd /blast/bin/blastp /lib64/ld-linux-x86-64.so.2 (0x7f6028019000) libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f6028019000) libz.so.1 => /lib/libz.so.1 (0x7f6027fff000) Error loading shared library libbz2.so.1: No such file or directory (needed by /blast/bin/blastp) libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f6028019000) libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f6028019000) libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f6028019000) Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /blast/bin/blastp) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f6027fe5000) Error relocating /blast/bin/blastp: BZ2_bzlibVersion: symbol not found Error relocating /blast/bin/blastp: BZ2_bzCompressEnd: symbol not found Error relocating /blast/bin/blastp: __sched_cpufree: symbol not found Error relocating /blast/bin/blastp: BZ2_bzReadClose: symbol not found Error relocating /blast/bin/blastp: __fprintf_chk: symbol not found Error relocating /blast/bin/blastp: BZ2_bzReadOpen: symbol not found Error relocating /blast/bin/blastp: __strncpy_chk: symbol not found

我们可以发现其依赖的动态库libbz2.so.1 和 ld-linux-x86-64.so.2 找不到,其实我们看到ld-linux-x86-64.so.2找不到的时候基本上可以判断出来底层依赖的操作系统可能有问题了,我们查看一下我们依赖的操作系统:

# cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.15.0 PRETTY_NAME="Alpine Linux v3.15" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://bugs.alpinelinux.org/"

我会发现我们用的基础镜像的操作系统是 alpine ,基本上里面阉割了很多linxu的很多基础库,那么我们改一下我们操作系统的基础镜像换到ubuntu里面测试一下:

# docker images -a ──(Mon,Feb07)─┘ REPOSITORY TAG IMAGE ID CREATED SIZE alpine 3.15.0 c059bfaa849c 2 months ago 5.59MB ubuntu 18.04 5a214d77f5d7 4 months ago 63.1MB

我们可以看到alpine镜像和ubuntu镜像大小有点差距,我们切到ubuntu里面和上面的方法一样下载可执行文件

# /blast/bin/blastp --version USAGE blastp [-h] [-help] [-import_search_strategy filename] [-export_search_strategy filename] [-task task_name] [-db database_name] [-dbsize num_letters] [-gilist filename] [-seqidlist filename] [-negative_gilist filename] [-negative_seqidlist filename] [-taxids taxids] [-negative_taxids taxids] [-taxidlist filename] [-negative_taxidlist filename] [-ipglist filename] 执行发现没有问题,ldd看一下文件的动态库依赖: # ldd /blast/bin/blastp linux-vdso.so.1 (0x00007ffdbc3f3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f64d57c6000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f64d55a9000) libbz2.so.1 => /lib/x86_64-linux-gnu/libbz2.so.1 (0x00007f64d5399000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f64d5195000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f64d4df7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f64d4a06000) /lib64/ld-linux-x86-64.so.2 (0x00007f64d59e5000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f64d47ee000) 所有的依赖都找到了,我们看一下我们的操作系统信息 # cat /etc/os-release NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.6 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic

其实我们仔细比对会发现 ubuntu的镜像里面会有文件

# file /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2: symbolic link to /lib/x86_64-linux-gnu/ld-2.27.so

而alpine里面并没有这个文件。

第二步:问题背后需要了解的原理知识有: 我们要熟悉并了解,我们常用的基础镜像的区别和差异,其中包括ubuntu和alpine和debian以及我们常用的Busybox

2. 我们要熟悉并且了解 linux的可执行程序的静态链接库和动态链接库的原理

如果大家觉得有帮助欢迎,点赞同,并鼓励,你的点赞是作者创作的最大动力。也欢迎付费咨询。



【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有